I see the travis build was set to run on 1.7 so I've set the compiler plugin to 1.7 also.

I'm not JLatexMath dev but I have few concerns. Currently, the project uses ant and the jar for deployment to maven central should be the one built by ant buildJar. I feel like having full-blown pom.xml and build.xml might lead to 2 different ways to build library producing two similar but still different jar files. I was going to open pull request that changes build.xml and adds targets to deploy to maven from ant. In that case compiler options specified in pom.xml will be ignored.

I agree with your concern about multiple ways of producing the same thing. If you want to concentrate on the ant build that's ok but it's to the detriment of this project I'd say. Very few prominent java projects use ant for the SDLC. It's either maven or gradle, and for really good reasons. I've migrated the project to maven at https://github.com/davidmoten/jlatexmath (in master branch) and it is in much better shape for it. For starters:

• the examples are also unit tests
• examples with dependencies (batik, xmlgraphics, etc) are built and tested with those dependencies
• all output is in target (not polluting the top-level of the project directory)
• tests are now first-class citizens and can be added to
• ide import is seamless and familiar to most
• maven does a hell of a lot for you by default that you don't have to define in ant build files
• all my open source maven projects are easily deployed to maven central using a single line command (release build, tagging, and all interaction with Sonatype repo is automated) . You could do this too.

It's a big looking change but is primarily shuffling files around in folders and some enhancements to the examples to make them tests. If you went this way you'd drop the ant build files.

My question for the project maintainers is are you interested in proceeding with such a change? Proof of concept is at the link above. Clone it and run mvn clean install. I'd make a PR if interested but would be good to hear your thoughts before I proceeded.

Oh I do want to add that I'm very impressed with the jlatexmath library! It's fantastic and I do appreciate the work that's been done. Just thinking it's time it was modernized in terms of build and test.

@calixteman deserves almost all the credits!

About the change, I think calixte and myself would be happy to accept the PR as long as it doesn't remove any features. (and that two build systems don't coexist)

Yep I agree with Sylvestre. So if you want to improve things (build, unit tests, ...) then everybody is welcome.

I'm all for maven. But as @sylvestre said we should make sure that migration to maven doesn't lose any functionality. Looking at build.xml there are a lot of various targets. @calixteman, can you help explaining what they do? And maybe some of them no longer used?

Targets: Macros, buildJarMinimal (jar without cyrillic and greek fonts?), fop, plugin, embedded.

Macros: you've an example on how to write your own macros in examples/Macros, "ant Macros" is here to build the example.
buildJarMinimal: jar without cyrillic and greek fonts which are put in separate jar files
fop: build the jlm (JLatexMath) jar and the fop plugin. The fop plugin is used to put latex in pdf files in using fop (https://xmlgraphics.apache.org/fop/), you've an example here: https://github.com/opencollab/jlatexmath/tree/master/plugin/fop/examples
plugin: fop-plugin only
embedded: jlm + fop-plugin in one jar file

Just like in any software, some piece might be too old or useless. So, don't hesitate to question things :)

Yep I certainly will question things, thanks. I'll get the basics going, report progress and then chase some details.

@nbeloglazov the current pom.xml will provide you the same jars you uploaded to the MCR, without examples, which is sufficient in most cases. I guess fop (embedded) should be published as well.

Doing it the maven way, one would create separate modules. One for jlm and fop which depends on jlm. Optionally, an example module too.

It would be nice to deploy jlm, e.g. with the Nexus Staging Maven plugin or Ant task, via the maven and/or ant build script. This way @calixteman and @sylvestre could do it themselves by executing the script. Of course, they would need the repository credentials.

@opcodevoid I agree with all you said. The current state of https://github.com/davidmoten/jlatexmath is that:

• a multi-module project is setup with this structure

jlatexmath-parent
    jlatexmath
    jlatexmath-fop
    jlatexmath-example-giws

• the Basic,Export, Macros examples have been subsumed for the moment into the core jlatexmath project as tests. We can of course change that so that they have their own child projects.
• in terms of release (I'll do that last naturally), I would use maven-release-plugin, nexus-staging-plugin and maven-gpg-plugin as per a parent pom that I use on all my open source projects at https://github.com/davidmoten/sonatype-parent/blob/master/pom.xml. In addition I have a script that makes the affair a one liner which I would drop into the project root. As a quick example this is how I release my projects to Maven Central:

cd some-project
release 0.5.2 <GPG_PASSWORD>

• The project builds the modules above successfully but I have yet to do full verification especially with the binaries produced by the ant build.

BTW, in terms of those examples I'm tempted to leave the Basic examples in the core jlatexmath project as tests (good to have some tests!) and move the others out into their own projects (also to distinguish their particular dependencies). I'll do that and see how it looks.

An update (at https://github.com/davidmoten/jlatexmath):

• The maven project structure now looks like this:

jlatexmath-parent
    jlatexmath-font-cyrillic
    jlatexmath-font-greek
    jlatexmath
    jlatexmath-fop
    jlatexmath-example-giws
    jlatexmath-example-export

• I added tests for image similarity (sqrt of mean squared difference between the pixel values) for the basic tests and the macro tests which are part of the core jlatexmath project. The similarity threshold will be something to tune by building on all platforms and checking for differences (e.g. anti-aliasing variations if they exist). At the moment linux builds (java 1.8.0.66) and windows 7 builds (java 1.8.0_102) produce exactly the same pixel values. MacOS and/or older jdks may be different; I'll find out. Do you guys expect the pngs to be produced deterministically in terms of pixel values?
• For jlatexmath-example-export I've been checking the svg and pdf files. Shaped versions only are working. I open the svg files in linux Image Viewer and visually check them. I'm not sure how to check the non-shaped versions because the font locations needs to be specified somehow to the SVG viewer. Any advice for testing these?
• jlatexmath-fop depends on fop 1.0 which depends on avalon-framework-* 4.3.1, batik-* 1.7, xml-graphics-commons 1.4 and a few others. Are these versions ok? I did experiment with using the latest fop 2.1 dependency and did work but I needed to patch the class FontCache for it to access fonts in jar files (see https://issues.apache.org/jira/browse/FOP-2532). Releases for fop look quite infrequent unfortunately but a fork could be released to Maven Central with the patch (with different maven coords obviously) if anyone saw value in using the latest versions.
• Anything depending on jlatexmath will depend transitively on jlatexmath-font-cyrillic and jlatexmath-font-greek by default. They can be excluded at will.
• I haven't made beefed up artifacts yet (including cyrillic and greek fonts with jlatexmath for instance). Is this a requirement or could users just include the three jars in the classpath? Certainly maven/gradle/ivy users would just add the single jlatexmath dependency and the other two would come with it by default.
• All of the project artifacts start with jlatexmath (rather than jlm for example). I think this is useful to standardize from a discoverability perspective because looking for artifacts in a Maven Central search (or your ide) starting with jlatexmath will come back with everything in one go. Let me know if you'd like to see the names changed though.
• Do you want to separate the other fonts into separate jars as well (euler, math, latin, etc...)?

Can I get a response to my questions?

i) about tests: I didn't make these kind of tests because of the difference of rendering between openjdk and sun jdk (as far as I remember, in Java 6 the font rendering was made by a third party library which was not free). So, if you want to do them, it's ok for me: your way to do will be mine ;)
ii) A way to do is to put the fonts in a system directory (it's why I renamed them with jlm_ prefix) and try to export svg or pdf in png (with ImageMagik for example)
iii) About fop: I don't know if this plugin is used... So do what you want with it.
iv) As far as I remember, I made jlm_cyrillic and jlm_greek to reduce the jar size of jlm (for Geogebra mainly which loads jlm from the web). I don't know anything about Maven, so do the best.
v) jlatexmath rather than jlm: I used to use jlm because I'm a lazy guy, so if you think that jlatexmath is better then go ahead !
vi) About the other fonts: I don't know, I 've no opinion. Maybe the best is to chat with users.

Exporting using FreeHEP works OK for embedding Fonts, eg

ImageIO.scanForPlugins();
UserProperties props = (UserProperties) PDFGraphics2D.getDefaultProperties();
props.setProperty(PDFGraphics2D.EMBED_FONTS, !textAsShapes);
props.setProperty(PDFGraphics2D.EMBED_FONTS_AS, FontConstants.EMBED_FONTS_TYPE1);
props.setProperty(AbstractVectorGraphicsIO.TEXT_AS_SHAPES, textAsShapes);
PDFGraphics2D.setDefaultProperties(props);

latexSpacing_withFonts.pdf

I'm close to submitting the PR for repackaging. I've cherry-picked recent commits but am ignoring the massive reindent d7d9456 commit because I end up with too many merge problems. Perhaps we could roll-back that commit and apply clean-up actions like that after?

By the way it was pleasing to see the png distance tests start failing when the italics render fix was added. I looked at the the images generated by the tests and updated the expected images with those generated ones. Once travis is incorporated we can see if they continue working on OpenJDK as well.

@davidmoten: sure you can revert the massive reindent (fyi I use astyle to do it).